在前幾天中,我們學會了如何透過「三要素公式」定義需求,並藉由「System Prompt」為 AI 建立資深工程師的思考框架。
然而,在串接後端 API、解析資料或生成制式物件時,很多開發者常遇到另一個難題:AI 的輸出格式飄忽不定。有時候它會好心附帶長篇解說,有時候命名規則又從駝峰式(camelCase)突然跳成蛇形(snake_case)。
如果我們希望 AI 「嚴格按照特定規格產出代碼,完全不走樣」,最有效的方法就是使用 Few-shot Prompting(少樣本提示法)。
一、什麼是 Few-shot Prompting?
在大型語言模型中,提問方式主要分為以下層次:
Zero-shot(零樣本提示):只給任務描述,完全不提供任何示範案例。
缺點:模型依賴機率分佈隨機猜測你偏好的結構,格式容易失控。
One-shot(單樣本提示):給予 1 個完整的「輸入與輸出對應範例」。
Few-shot(少樣本提示):提供 2~3 個具代表性的「輸入 ➔ 輸出範例」,建立隱性規則。
優勢:模型會強烈模仿範例中的命名規則、型別對應、縮排、註解風格與錯誤處理邏輯,極少出現格式偏差。
二、實戰場景:自然語言欄位定義 ➔ 嚴格 Java Record DTO
在現代 Java(Java 17+)開發中,我們常用不可變的 record 來作為資料傳輸物件(DTO)。現在我們希望給 AI 一段隨意的中文資料庫欄位或需求描述,讓它精準轉換成符合 Spring Boot / Jackson 規範的 Record 結構。
【Few-shot Prompt 範本】
請擔任資深 Java 開發者。根據給定的欄位描述,將其轉換為 Java 17 record 格式。
規則:
類別必須為 public record。
時間型別一律使用 java.time.LocalDateTime。
金額一律使用 java.math.BigDecimal。
加上 @JsonProperty 映射原始蛇形命名(snake_case)。
[範例 1]
輸入:使用者基本資料,包含 user_id (長整數), user_name (字串), registered_at (建立時間)。
輸出:
public record UserDto(
@JsonProperty("user_id") Long userId,
@JsonProperty("user_name") String userName,
@JsonProperty("registered_at") LocalDateTime registeredAt
) {}
[範例 2]
輸入:商品交易項目,包含 item_id (長整數), price (單價金額), quantity (整數數量)。
輸出:
public record OrderItemDto(
@JsonProperty("item_id") Long itemId,
@JsonProperty("price") BigDecimal price,
@JsonProperty("quantity") Integer quantity
) {}
[正式任務]
輸入:發票資訊,包含 invoice_no (字串發票號碼), total_amount (總金額), is_tax_included (是否含稅布林值), issued_at (開立時間)。
輸出:
import com.fasterxml.jackson.annotation.JsonProperty;
import java.math.BigDecimal;
import java.time.LocalDateTime;
public record InvoiceDto(
@JsonProperty("invoice_no") String invoiceNo,
@JsonProperty("total_amount") BigDecimal totalAmount,
@JsonProperty("is_tax_included") Boolean isTaxIncluded,
@JsonProperty("issued_at") LocalDateTime issuedAt
) {}
可以看到:
型別一致性:金額被自動指定為 BigDecimal,時間對應為 LocalDateTime,沒有變成普通的 double 或 String。
命名規範:Java 欄位自動轉換成標準駝峰式(如 isTaxIncluded),同時完整保留 @JsonProperty 的原始名稱對應。
無多餘廢話:AI 完全依照 Few-shot 範例的格式,乾淨利落地交出程式碼區塊。
三、進階應用:用 Few-shot 約束「單元測試驗證模式」
除了 DTO 定義,Few-shot 在生成單元測試時更具殺傷力。
例如團隊內部有一套統一的 AAA 模式(Arrange, Act, Assert) 格式,或者習慣使用 AssertJ 語法:
只要在 Prompt 中先提供一個標準的 @Test 範例(標明 Arrange、Act、Assert 區塊)。
接著貼上目標方法,AI 就會完全套用相同的變數命名與斷言寫法,省去後續人工 Code Review 與排版的大量時間。
四、工程師實務建議
範例不在多,在於邊界覆蓋:通常 2 至 3 個範例 就能達到極高穩定度。過多範例反而消耗上下文視窗(Context Window)與 Token 額度。
範例要展示極端情況:例如示範一個「允許為空(Nullable)」的欄位如何處理,AI 在遇到類似情境時就會自動模仿。
消除雜訊輸出:在範例末尾直接留下 輸出: 或 Code:,利用生成補全的特性讓 AI 直接從代碼第一行開始接續,杜絕「好的,這是為您生成的...」等前綴廢話。
今日小結與預告
今天我們實踐了 Few-shot Prompting,掌握了如何透過示範樣板「鎖死」AI 的輸出型別與架構風格。到今天為止,我們已經完成了第一階段的「工具配置與提示詞核心功法」。